@kandersolar This is technically a breaking change. Do we want a deprecation period (which will slow down the GSoC project a lot - probably not a good reason not to do it)?

Do we want a deprecation period

I'd love one, but unfortunately we don't have a good mechanism for deprecating dict/dataframe keys (see #2530). If we go forward with this change, I think all we can do is just do it.

Not related, but fyi: I need to review the discussion about not including empty components, since it's a change in direction and I don't remember the arguments for/against.

I need to review the discussion about not including empty components

There is some discussion about including / not including empty components in #2750 and #2527. As far as I'm aware:

Pros of including:

• makes it explicit that a given model does not include a given component, e.g. that haydavies does not account for a horizon brightening component, whereas if it is simply missing this will be more implicit
• standard outputs across different functions

Pros of not including:

• cleaner
• more flexibility - if another model to be included in the future includes an additional component other than isotropic, circumsolar and horizon brightening, we don't have to retroactively change all existing functions to keep consistency
• less messy - if you look at Diffuse components with Klucher #2794, it's looking like the decision will be to not include components for klucher. If we set all klucher components to zero, it will look like this model does not consider components at all, when in fact it does - it's just that they are all multiplied by each other and therefore difficult to extricate.

I think the low level transposition functions should return only what is relevant to that model and nothing more. The wrapper functions and object layers smooth over the differences for users that want a completely consistent API.